2.1 Overview of the Interface Process M2 has created an Interface infrastructure which operates between other system/s operated by the client (information is restricted to the iBroker system within this document) and the M2CRM /m2Controller Applications and Services. This Interface enables the client to automatically transfer movements from within their systems to the M2 system with minimal client input. It consists of a number of applications and steps which provide the client with the facilities to undertake one-off initial loads of historical movements into M2CRM to bring the end-user M2 portfolios from their starting position up to the present, and then daily updates into M2CRM of movements processed through the client in-house system and third party systems. Once M2 end-users are set up within M2CRM and after the initial load of historical movements is completed, a daily update run will keep the end-users M2CRM Portfolio in sync with any other system 'interfaced' to M2. 2.2 Explanation of the Steps The extraction of transactions from the in-house iBroker system into the myM2 / m2CRM System has 5 steps. With the iBroker interface, the last step is automatic and requires no input from the client. These steps are run regardless of whether the extract is for an initial load of historical movements or for the daily update. The first two steps have facilities to enable the viewing of the data and its repair (or removal from transmission) while steps 3 and 4 require only minimal input from the Client. The following section gives an explanation of each of the steps. 2.2.1 Extractor The first step is the extraction of movements from iBroker. The purpose of the Extractor module is to extract the daily (or ad hoc or historical) movements from iBroker in the original format as supplied by the source system and to write them in a known format to an intermediate data storage area for review and repair (if necessary). This data storage area is called the RawInput queue. The Extractor step for each different in-house system is unique to that system and is therefore custom-built. 2.2.2 Adaptor The second step is the Adaptor and the purpose of the Adaptor is to convert the RawInput queue messages extracted from iBroker into standard M2 XML Interface format movements. XML is the internal message format used throughout M2. There can be a number of Adaptors running if the client site has interfaces linked to more than one source system (e.g. one for the iBroker Trading system and another one for a Bank Cash Management system). Once this is completed, the movements are released into the Interface Submission queue. Each Adaptor has it's own set of rules required to convert the RawInput queue data into the various M2 XML message formats. The Adaptor applies these rules to make sure that the RawInput queue data is valid and acceptable to the M2 system and then submits the converted message to the Interface Submission queue. It may be possible that some RawInput queue data is rejected or bypassed depending on the rules for the Adaptor. In some cases these rejected or bypassed input messages can be repaired and re-processed but typically they are rejected or bypassed and the related RawInput queue data is discarded. In these cases the movements will need to be entered manually into M2CRM. The primary type of data to be accepted by the M2 Interface are holding movements which support the increase or decrease in the quantity and cost-base of a specific asset which may be either a cash holding or an investment type holding such as a share or bond. These are converted to the 'M001' series messages in the M2 XML internal format and cover all the primary movements in M2 such as Buy, Sell, AssetIn, AssetOut, Deposit, Withdrawal, Dividends, Interest, Payments etc. In a future release, the Adaptor program will be deployed as a background task under the control of the m2Controller application. The Adaptor will run in the background continuously and periodically check to see if there are new messages waiting on the RawInput queue to be processed. Once all the RawInput queue messages have been processed, the Adaptor will go to 'sleep' for a period and then it will 'wake' again and check for more messages to process. The status of the Adaptor process will be able to be monitored at any time from the Services tab within the System Admin section of m2Controller. Each Adaptor registered within the m2Controller is displayed under the Adaptors sub-section in the Service Status list. The status of each Adaptor is displayed when you select a specific Adaptor in the list along with the recent activity log entries. The Adaptors can also be stopped and started from this same screen. However, for now this process is manual and is explained below. 2.2.3 Release The third stage is the Release process which enables the messages on the XML Interface Submission queue to be released individually (or as a block) for submission to the M2 Service. This is done through the m2Controller application. 2.2.4 Submission The fourth step submits the released messages to the m2Central Service. This is a background task and other than starting requires no Operator input by the Client. The Submission process, once started is constantly listening for new released messages. 2.2.5 Update The last step is the Update process which receives messages on the M2Central server and updates the end-users Holdings for viewing from myM2 or M2CRM. This process requires no operator input at all and is always active awaiting submitted messages.